feature: run query via livequery #9864
Open
+387
−1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
🚀 Thanks for opening this pull request! |
📝 WalkthroughWalkthroughAdds a LiveQuery "query" operation: request schema, server handler to execute find queries and return results, client API to push query results, and tests validating result delivery, field selection, where constraints, and error paths. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant SDK as LiveQuery Client SDK
participant WS as WebSocket Server
participant Srv as ParseLiveQueryServer
participant Sub as Subscription Registry
participant DB as Data Store
rect rgba(230,240,255,0.35)
note left of SDK: client sends a query tied to a subscriptionId
end
SDK->>WS: { op: "query", requestId, id: subscriptionId, where, keys }
WS->>Srv: route "query" request
Srv->>Sub: lookup subscription(subscriptionId)
alt subscription found
Srv->>Srv: resolve auth (subscription.sessionToken || client.sessionToken || master)
Srv->>DB: find(className, where, keys)
DB-->>Srv: results[]
Srv->>WS: push { op: "result", requestId, clientId, installationId, results }
WS-->>SDK: deliver "result"
else subscription missing
Srv->>WS: push error { op: "error", requestId, ... }
WS-->>SDK: deliver error
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (13)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
2 tasks
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## alpha #9864 +/- ##
==========================================
- Coverage 93.02% 92.43% -0.59%
==========================================
Files 187 187
Lines 15096 15216 +120
Branches 174 186 +12
==========================================
+ Hits 14043 14065 +22
- Misses 1041 1134 +93
- Partials 12 17 +5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
spec/ParseLiveQueryQuery.spec.js (1)
6-19: Remove unnecessarydonecallback from synchronous beforeEach.The
beforeEachfunction is synchronous but declares adoneparameter and calls it. Jasmine only requires thedonecallback for asynchronous setup. This adds unnecessary overhead.Apply this diff:
- beforeEach(function (done) { + beforeEach(function () { Parse.CoreManager.getLiveQueryController().setDefaultLiveQueryClient(null); // Mock ParseWebSocketServer const mockParseWebSocketServer = jasmine.createSpy('ParseWebSocketServer'); jasmine.mockLibrary( '../lib/LiveQuery/ParseWebSocketServer', 'ParseWebSocketServer', mockParseWebSocketServer ); // Mock Client pushError const Client = require('../lib/LiveQuery/Client').Client; Client.pushError = jasmine.createSpy('pushError'); - done(); });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
spec/ParseLiveQueryQuery.spec.js(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-04-30T19:31:35.344Z
Learnt from: RahulLanjewar93
PR: parse-community/parse-server#9744
File: spec/ParseLiveQuery.spec.js:0-0
Timestamp: 2025-04-30T19:31:35.344Z
Learning: In the Parse Server codebase, the functions in QueryTools.js are typically tested through end-to-end behavior tests rather than direct unit tests, even though the functions are exported from the module.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
🧬 Code graph analysis (1)
spec/ParseLiveQueryQuery.spec.js (2)
src/LiveQuery/RequestSchema.js (1)
query(152-163)spec/helper.js (1)
reconfigureServer(171-205)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (12)
- GitHub Check: PostgreSQL 17, PostGIS 3.5
- GitHub Check: PostgreSQL 15, PostGIS 3.4
- GitHub Check: PostgreSQL 16, PostGIS 3.5
- GitHub Check: MongoDB 8, ReplicaSet
- GitHub Check: PostgreSQL 15, PostGIS 3.5
- GitHub Check: Redis Cache
- GitHub Check: Node 20
- GitHub Check: Node 18
- GitHub Check: MongoDB 7, ReplicaSet
- GitHub Check: PostgreSQL 15, PostGIS 3.3
- GitHub Check: MongoDB 6, ReplicaSet
- GitHub Check: Docker Build
🔇 Additional comments (7)
spec/ParseLiveQueryQuery.spec.js (7)
21-27: LGTM! Proper async cleanup.The cleanup properly closes LiveQuery clients and restores mocked libraries, ensuring test isolation.
29-35: LGTM! Well-structured test helper.The helper cleanly creates and registers a mock client with a spy for result verification.
37-64: LGTM! Comprehensive subscription setup helper.The helper correctly establishes subscription state on both server and client sides, mirroring the production subscription structure.
124-150: LGTM! Comprehensive error handling coverage.These tests properly validate error paths when clientId is missing or subscription doesn't exist, ensuring robust error handling.
163-167: Verify serverURL configuration in field filtering and where constraint tests.Similar to the first test, these tests use
serverURL: 'http://localhost:1337/parse'whilereconfigureServerlikely uses a different port. Ensure this doesn't cause query execution failures.The verification script from the earlier comment applies here as well.
Also applies to: 224-228
152-211: LGTM! Field filtering validation is thorough.The test correctly validates that the
keysparameter restricts returned fields, checking both included and excluded fields.
213-270: LGTM! Where clause filtering is properly tested.The test validates that query constraints are correctly applied, returning only matching objects.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
spec/ParseLiveQueryQuery.spec.js (1)
76-81: Previous serverURL concern is resolved.Line 80 now correctly uses
Parse.serverURLinstead of a hard-coded URL, ensuring the LiveQueryServer and test Parse Server use the same endpoint.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
spec/ParseLiveQueryQuery.spec.js(1 hunks)
🧰 Additional context used
🧠 Learnings (9)
📓 Common learnings
Learnt from: EmpiDev
Repo: parse-community/parse-server PR: 9770
File: src/triggers.js:467-477
Timestamp: 2025-08-27T12:33:06.237Z
Learning: In the Parse Server codebase, maybeRunAfterFindTrigger is called in production with Parse.Query objects constructed via withJSON(), so the plain object query handling bug only affects tests, not production code paths.
📚 Learning: 2025-04-30T19:31:35.344Z
Learnt from: RahulLanjewar93
Repo: parse-community/parse-server PR: 9744
File: spec/ParseLiveQuery.spec.js:0-0
Timestamp: 2025-04-30T19:31:35.344Z
Learning: In the Parse Server codebase, the functions in QueryTools.js are typically tested through end-to-end behavior tests rather than direct unit tests, even though the functions are exported from the module.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
📚 Learning: 2025-05-09T09:59:06.289Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 9445
File: spec/ParseLiveQuery.spec.js:1340-1375
Timestamp: 2025-05-09T09:59:06.289Z
Learning: Tests in the parse-server repository should use promise-based approaches rather than callback patterns with `done()`. Use a pattern where a Promise is created that resolves when the event occurs, then await that promise.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
📚 Learning: 2025-08-26T14:06:31.853Z
Learnt from: EmpiDev
Repo: parse-community/parse-server PR: 9770
File: spec/CloudCode.spec.js:446-469
Timestamp: 2025-08-26T14:06:31.853Z
Learning: In the Parse Server codebase, when handling query objects in maybeRunAfterFindTrigger, objects without a where property that contain options like limit/skip should be treated as query JSON with an empty where clause using the spread pattern { where: {}, ...query }, not nested as { where: query }.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
📚 Learning: 2025-05-04T20:41:05.147Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 9445
File: spec/ParseLiveQuery.spec.js:1312-1338
Timestamp: 2025-05-04T20:41:05.147Z
Learning: New tests in the parse-server repository should use async/await with promise-based patterns rather than callback patterns with `done()`.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
📚 Learning: 2025-05-09T09:59:06.289Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 9445
File: spec/ParseLiveQuery.spec.js:1340-1375
Timestamp: 2025-05-09T09:59:06.289Z
Learning: New tests in the parse-server repository should use async/await with promise-based patterns rather than callback patterns with `done()`. The preferred pattern is to create a Promise that resolves when an expected event occurs, then await that Promise.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
📚 Learning: 2025-08-27T12:33:06.237Z
Learnt from: EmpiDev
Repo: parse-community/parse-server PR: 9770
File: src/triggers.js:467-477
Timestamp: 2025-08-27T12:33:06.237Z
Learning: In the Parse Server codebase, maybeRunAfterFindTrigger is called in production with Parse.Query objects constructed via withJSON(), so the plain object query handling bug only affects tests, not production code paths.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
📚 Learning: 2025-08-27T09:08:34.252Z
Learnt from: EmpiDev
Repo: parse-community/parse-server PR: 9770
File: src/triggers.js:446-454
Timestamp: 2025-08-27T09:08:34.252Z
Learning: When analyzing function signature changes in Parse Server codebase, verify that call sites are actually incorrect before flagging them. Passing tests are a strong indicator that function calls are already properly aligned with new signatures.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
📚 Learning: 2025-10-16T19:27:05.311Z
Learnt from: Moumouls
Repo: parse-community/parse-server PR: 9883
File: spec/CloudCodeLogger.spec.js:410-412
Timestamp: 2025-10-16T19:27:05.311Z
Learning: In spec/CloudCodeLogger.spec.js, the test "should log cloud function triggers using the silent log level" (around lines 383-420) is known to be flaky and requires the extra `await new Promise(resolve => setTimeout(resolve, 100))` timeout after awaiting `afterSavePromise` for reliability, even though it may appear redundant.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
🧬 Code graph analysis (1)
spec/ParseLiveQueryQuery.spec.js (2)
src/LiveQuery/RequestSchema.js (1)
query(152-163)spec/helper.js (1)
reconfigureServer(171-205)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (13)
- GitHub Check: PostgreSQL 16, PostGIS 3.5
- GitHub Check: PostgreSQL 15, PostGIS 3.3
- GitHub Check: MongoDB 8, ReplicaSet
- GitHub Check: PostgreSQL 15, PostGIS 3.5
- GitHub Check: PostgreSQL 18, PostGIS 3.6
- GitHub Check: PostgreSQL 15, PostGIS 3.4
- GitHub Check: Node 18
- GitHub Check: PostgreSQL 17, PostGIS 3.5
- GitHub Check: MongoDB 6, ReplicaSet
- GitHub Check: Redis Cache
- GitHub Check: Node 20
- GitHub Check: MongoDB 7, ReplicaSet
- GitHub Check: Docker Build
🔇 Additional comments (4)
spec/ParseLiveQueryQuery.spec.js (4)
21-27: LGTM!The afterEach hook properly uses async/await and performs necessary cleanup.
29-64: LGTM!The helper functions are well-structured and provide clean setup for mock clients and subscriptions.
124-150: LGTM!The error path tests properly validate that
Client.pushErroris called when clientId is missing or subscription doesn't exist. Using empty config is acceptable for these early-failure error tests.
152-270: LGTM!These tests provide excellent coverage of the query operation's field filtering (keys) and where constraint features. The assertions properly validate that only selected fields are returned and only matching objects are included.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
spec/ParseLiveQueryQuery.spec.js (1)
65-270: Strong test coverage for the core query operation.The test suite thoroughly validates:
- Basic query execution with result verification
- Error handling for missing client/subscription contexts
- Field filtering via
keysparameter- Where clause constraint application
All tests properly use async/await and the
serverURLfix from the previous review is correctly applied.Optional: Consider expanding test coverage.
To further harden the feature, you might add tests for:
- ACL enforcement (users without read permissions)
- Session token scenarios (non-master key queries)
- Query options:
limit,skip,order- Error responses for invalid/malformed queries
- Edge case: empty result sets
These are not blockers for this PR but could improve long-term reliability.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
spec/ParseLiveQueryQuery.spec.js(1 hunks)
🧰 Additional context used
🧠 Learnings (9)
📓 Common learnings
Learnt from: EmpiDev
Repo: parse-community/parse-server PR: 9770
File: src/triggers.js:467-477
Timestamp: 2025-08-27T12:33:06.237Z
Learning: In the Parse Server codebase, maybeRunAfterFindTrigger is called in production with Parse.Query objects constructed via withJSON(), so the plain object query handling bug only affects tests, not production code paths.
Learnt from: EmpiDev
Repo: parse-community/parse-server PR: 9770
File: spec/CloudCode.spec.js:446-469
Timestamp: 2025-08-26T14:06:31.853Z
Learning: In the Parse Server codebase, when handling query objects in maybeRunAfterFindTrigger, objects without a where property that contain options like limit/skip should be treated as query JSON with an empty where clause using the spread pattern { where: {}, ...query }, not nested as { where: query }.
📚 Learning: 2025-04-30T19:31:35.344Z
Learnt from: RahulLanjewar93
Repo: parse-community/parse-server PR: 9744
File: spec/ParseLiveQuery.spec.js:0-0
Timestamp: 2025-04-30T19:31:35.344Z
Learning: In the Parse Server codebase, the functions in QueryTools.js are typically tested through end-to-end behavior tests rather than direct unit tests, even though the functions are exported from the module.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
📚 Learning: 2025-05-09T09:59:06.289Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 9445
File: spec/ParseLiveQuery.spec.js:1340-1375
Timestamp: 2025-05-09T09:59:06.289Z
Learning: Tests in the parse-server repository should use promise-based approaches rather than callback patterns with `done()`. Use a pattern where a Promise is created that resolves when the event occurs, then await that promise.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
📚 Learning: 2025-05-09T09:59:06.289Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 9445
File: spec/ParseLiveQuery.spec.js:1340-1375
Timestamp: 2025-05-09T09:59:06.289Z
Learning: New tests in the parse-server repository should use async/await with promise-based patterns rather than callback patterns with `done()`. The preferred pattern is to create a Promise that resolves when an expected event occurs, then await that Promise.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
📚 Learning: 2025-05-04T20:41:05.147Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 9445
File: spec/ParseLiveQuery.spec.js:1312-1338
Timestamp: 2025-05-04T20:41:05.147Z
Learning: New tests in the parse-server repository should use async/await with promise-based patterns rather than callback patterns with `done()`.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
📚 Learning: 2025-08-26T14:06:31.853Z
Learnt from: EmpiDev
Repo: parse-community/parse-server PR: 9770
File: spec/CloudCode.spec.js:446-469
Timestamp: 2025-08-26T14:06:31.853Z
Learning: In the Parse Server codebase, when handling query objects in maybeRunAfterFindTrigger, objects without a where property that contain options like limit/skip should be treated as query JSON with an empty where clause using the spread pattern { where: {}, ...query }, not nested as { where: query }.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
📚 Learning: 2025-08-27T12:33:06.237Z
Learnt from: EmpiDev
Repo: parse-community/parse-server PR: 9770
File: src/triggers.js:467-477
Timestamp: 2025-08-27T12:33:06.237Z
Learning: In the Parse Server codebase, maybeRunAfterFindTrigger is called in production with Parse.Query objects constructed via withJSON(), so the plain object query handling bug only affects tests, not production code paths.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
📚 Learning: 2025-08-27T09:08:34.252Z
Learnt from: EmpiDev
Repo: parse-community/parse-server PR: 9770
File: src/triggers.js:446-454
Timestamp: 2025-08-27T09:08:34.252Z
Learning: When analyzing function signature changes in Parse Server codebase, verify that call sites are actually incorrect before flagging them. Passing tests are a strong indicator that function calls are already properly aligned with new signatures.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
📚 Learning: 2025-10-16T19:27:05.311Z
Learnt from: Moumouls
Repo: parse-community/parse-server PR: 9883
File: spec/CloudCodeLogger.spec.js:410-412
Timestamp: 2025-10-16T19:27:05.311Z
Learning: In spec/CloudCodeLogger.spec.js, the test "should log cloud function triggers using the silent log level" (around lines 383-420) is known to be flaky and requires the extra `await new Promise(resolve => setTimeout(resolve, 100))` timeout after awaiting `afterSavePromise` for reliability, even though it may appear redundant.
Applied to files:
spec/ParseLiveQueryQuery.spec.js
🧬 Code graph analysis (1)
spec/ParseLiveQueryQuery.spec.js (2)
src/LiveQuery/RequestSchema.js (1)
query(152-163)spec/helper.js (1)
reconfigureServer(171-205)
🔇 Additional comments (2)
spec/ParseLiveQueryQuery.spec.js (2)
6-26: LGTM! Previous issues resolved.The
beforeEachandafterEachhooks are now correctly implemented using modern async/await patterns. The hard-codedserverURLissue from the previous review has also been addressed in the test setup below.
28-63: LGTM! Helper functions follow established patterns.The mock client and subscription helpers correctly set up the test infrastructure, mirroring the patterns used in
ParseLiveQueryServer.spec.js. ThepushResultspy enables verification of query results, and thesubscriptionInfostructure properly captures field filtering viakeys.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request
Issue
Closes: #9086
Added LiveQuery
queryoperation to execute queries through existing WebSocket subscriptions, eliminating separate REST API calls for data syncing.Client SDK Changes Required:
Add
resultevent type to LiveQuery constantsHandle
resultmessages in WebSocket handlerAdd
query()method to subscription classAdd tests
Summary by CodeRabbit
New Features
Bug Fixes
Tests